Have a look at how to rebase this branch on top of the main branch (instead of merging the main branch into it) and how to squash commits + force push with git, you may need a few tries to make it right, but that's perfectly normal for a first time contributor.

Hi, do I need to add the path to stropts.h anywhere to make sure the build is successful? It seems that the test keeps failing with cannot find putmsg()

#include <zephyr/ztest.h>
#include <stropts.h>
#include <errno.h>

ZTEST(stropts, test_putmsg)
{
	int ret = putmsg(0, NULL, NULL, 0);

	zassert_equal(ret, -1, "Expected return value -1, got %d", ret);
	zassert_equal(errno, ENOSYS, "Expected errno ENOSYS, got %d", errno);
}

ZTEST_SUITE(stropts, NULL, NULL, NULL, NULL, NULL);

The following west manifest projects have been modified in this Pull Request:

Note: This message is automatically posted and updated by the Manifest GitHub Action.

Hi @ycsin I got my tests running, I also did a rebase, squash, and force. Does this look right?

Hi @ycsin I got my tests running, I also did a rebase, squash, and force. Does this look right?

It seems like you merged the upstream main branch into your PR branch instead of rebasing your PR branch on top of the upstream main branch, that results in a lot of commits and file changes that are not related to your changes.

This can be done (in your PR branch) if you are using VSCode (after fetching remote branch):

As things stand now, it might be easier for you to simply backup your work, hard reset this PR branch to upstream main, then apply your changes on top again.

It seems like you merged the upstream main branch into your PR branch instead of rebasing your PR branch on top of the upstream main branch, that results in a lot of commits and file changes that are not related to your changes.

This makes sense, my bad! @ycsin Would it make more sense to make a new PR? Since this PR will be looked at by people who want to commit to STREAMS and the current conversation might be too long to parse through?

It seems like you merged the upstream main branch into your PR branch instead of rebasing your PR branch on top of the upstream main branch, that results in a lot of commits and file changes that are not related to your changes.

This makes sense, my bad! @ycsin Would it make more sense to make a new PR? Since this PR will be looked at by people who want to commit to STREAMS and the current conversation might be too long to parse through?

People won't be notified if PR is still in draft, I think it should be fine to clean this up within this PR, this happens very often to new contributors.

@ycsin rebased and squashed, and made sure all tests pass!

@AbhinavMir this needs a rebase

@ycsin @cfriedt Just wondering if we could merge and close this PR? I'd love to get started on the other STREAMS APIs. I suppose I could branch off of this, rebase and send in fixes for those, but just wondering for sake of convenience.

maybe I missing something here, but is the purpose of this PR to just introduce putmsg as a not supported implementation?

int putmsg(int fildes, const struct strbuf *ctlptr, const struct strbuf *dataptr, int flags)
{
	ARG_UNUSED(fildes);
	ARG_UNUSED(ctlptr);
	ARG_UNUSED(dataptr);
	ARG_UNUSED(flags);

	errno = ENOSYS;
	return -1;
}

so just a placeholder?

maybe I missing something here, but is the purpose of this PR to just introduce putmsg as a not supported implementation?

That is correct. The symbol needs to exist so that a conformant application can link.

Looks like docs should be updated? https://docs.zephyrproject.org/latest/services/portability/posix/option_groups/index.html#xopen-streams
I haven't been paying attention but I'm guessing this might be true for other recently added functions too (sched_getscheduler(), sched_getparam(), ...?)

The symbol needs to exist so that a conformant application can link.

link yes, but it will not work if the implementation just returns an error....

How the documentation will need to change i.e. in doc/services/portability/posix/option_groups/index.rst

would we put a "yes" next to putmsg? I guess not, right?, because it is not implemented.

would we put a "yes" next to putmsg? I guess not, right?, because it is not implemented.

it is 'supported' (in terms of 'can be compiled') but the function isn't implemented (ENOSYS), I agree that we can probably note in the documentation about these unimplemented functions (in another PR) just to be clear

I'm guessing this might be true for other recently added functions too (sched_getscheduler(), sched_getparam(), ...?)

yes you are right

Hi @AbhinavMir!
Congratulations on getting your very first Zephyr pull request merged 🎉🥳. This is a fantastic achievement, and we're thrilled to have you as part of our community!

To celebrate this milestone and showcase your contribution, we'd love to award you the Zephyr Technical Contributor badge. If you're interested, please claim your badge by filling out this form: Claim Your Zephyr Badge.

Thank you for your valuable input, and we look forward to seeing more of your contributions in the future! 🪁